python@3.14: move _dbm to python-gdbm@3.14 on Linux#278336
Conversation
aadb08d to
ae39dec
Compare
|
I wonder if we should do this on macOS too given https://docs.python.org/3/library/dbm.html#module-dbm.ndbm Warning The NDBM library shipped as part of macOS has an undocumented limitation on the size of values, which can result in corrupted database files when storing values larger than this limit. Reading such corrupted files can result in a hard crash (segmentation fault). EDIT: Though not a blocker for this PR. Just something we may want to consider to avoid problematic NDBM given we used to ship with functional GDBM compatibility layer in Python 3.10 and older. |
|
macOS failures are unrelated as changed only impact Linux.
|
|
Caution Please do not push to this PR branch before the bottle commits have been pushed, as this results in a state that is difficult to recover from. If you need to resolve a merge conflict, please use a merge commit. Do not force-push to this PR branch. |
Seeing if we can reduce Berkeley DB usage.
For Python, most Linux distros just use
gdbmrather than BDB, but Homebrew has a harder time directly linking to GPL dependencies as we cannot rely on GNU's "system library" exception.Approach here would be making dependents that need
dbm.ndbmsupport add:Also, since Python 3.13,
dbmprovidesdbm.sqlite3so there is at least some functionality available withoutpython-gdbminstalled. So I expect lifespan ofberkeley-db@5to be aligned to deprecation date of either Python 3.12 (2028-10) or 3.13 (2029-10) depending on whether we backport to Python 3.13.python-gdbm@3.14is revision bumped to avoid missing _dbm in casepython@3.14is reinstalled but notpython-gdbm@3.14.python@3.14does not need a revision bump as modules are installed in non-conflicting directories. If both _dbm exist, original would be loaded first and should work as expected.